Having second thoughts about using shopify search for this.

I'm sure use of shopify search is near-zero, but should we stick to our SemVer committment, and create a new command? We could fix the existing command or just deprecate it.

This would also give us an opportunity to apply our CLI design guidelines to a new command. e.g. The shopify search use of positional arguments is against those guidelines.

Looking through the existing cli monorail schema, nothing stands out to me as a pre-existing fit for capturing doc search results. My suggestion would be that we add a new monorail field cmd_doc_search_result where we put the json result, then when we extend to validate and other commands, add in related fields like cmd_validate_passes.

Additionally, currently the args monorail field is flagged as PII, so anything we are passing in there (e.g. the search query) is redacted after 30 days. The pattern followed here for cases where we want to retain the flags for longer duration is to additionally log them in a separate field, so we might consider also adding a field like cmd_doc_search_query to explicitly log the search query and not flag it as PII to retain. Not directly related to this PR, but this also is impacting any vars we are saving through the agent env vars, as they're subject to the same PII policy.

So, if this sounds reasonable, I can update the monorail schema to include cmd_doc_search_query and cmd_doc_search_result. For doc fetch, maybe I'll also add in cmd_doc_fetch_query (but skip result there, since it's just the docs content for the requested link?)

@kaylarobinson077 - I think the cleaner solution for tracking search would be on the search handler. That one hanbdler is where all search traffic goes already

Differences in type declarations

We detected differences in the type declarations generated by Typescript for this branch compared to the baseline ('main' branch). Please, review them to ensure they are backward-compatible. Here are some important things to keep in mind:

• Some seemingly private modules might be re-exported through public modules.
• If the branch is behind main you might see odd diffs, rebase main into this branch.

New type declarations

We found no new type declarations in this PR

Existing type declarations

@@ -47,6 +47,22 @@ export declare function isUserAccount(account: AccountInfo): account is UserAcco
  * @returns True if the account is a ServiceAccount.
  */
 export declare function isServiceAccount(account: AccountInfo): account is ServiceAccountInfo;
+/**
+ * Reports whether the CLI already has stored credentials, without prompting the
+ * user, opening a browser, or making any network request.
+ *
+ * This is a passive, side-effect-free check: it reads the local session store and
+ * returns  when at least one valid session is present. Unlike the
+ *  functions, it never triggers a login flow and never logs
+ * the user out. Because it does not contact the network, it cannot tell whether the
+ * stored token is currently valid/unexpired — only that credentials exist locally.
+ *
+ * Intended for best-effort, opportunistic behaviour (for example, enriching
+ * telemetry only for users who are already logged in).
+ *
+ * @returns True if local credentials exist, false otherwise.
+ */
+export declare function sessionExists(): Promise<boolean>;
 /**
  * Ensure that we have a valid session with no particular scopes.
  *

@kaylarobinson077 - I think the cleaner solution for tracking search would be on the search handler. That one hanbdler is where all search traffic goes already

​Is the search handler something that lives within this command, or is it something outside of CLI? My home is that we can track the query and result in the regular CLI monorail event, so everything lives together in one place in terms of where the data lands.